Most embedded systems need to be self-reliant; it is not practical to wait for a user to intervene and reboot the system when an anomaly is encountered. Such system anomalies may include, but are not limited to, software or hardware (e.g., bus) experiencing a bus hang event, deadlocks, peripheral device failures, etc. In a typical hardware system, such as, for example, a system-on-chip (SoC) interconnect, data processing system, etc., system anomalies are generally handled through a system reset procedure.
A watchdog timer is often used to detect system anomalies and reset a system processor when such anomalies occur. Generally, a watchdog timer is a piece of hardware, often built into a microcontroller or other processor, that has the ability to initiate a system reset when it determines that the system has hung or is no longer executing a correct sequence of code. A watchdog timer is often based on a counter that counts down from some predetermined initial value to zero (or likewise, counts up from zero to a predetermined final value). Embedded software typically selects the counter's predetermined initial value (or final value in the case of a count-up scheme) and periodically services (e.g., restarts) the counter before it approaches zero, or an alternative predetermined final value. If the counter ever reaches its predetermined value before being restarted, a system malfunction is presumed to have occurred and the processor's, or the SoC's, reset line is asserted.
Once a system reset occurs, however, there is typically a considerable recovery time for the system to begin functioning normally. The recovery time is generally a function of a length of the watchdog timeout period plus the time it takes the system to reset and perform its initialization, which varies based, at least in part, on the amount of persistent data required. Because the recovery time causes significant delay in the system, performing a reset of the system is undesirable.
Systems typically include a default slave device which receives any core accesses to undefined system memory. However, accesses to undefined memory are typically static errors attributable to software and are not due to transient hardware conditions. Such undefined accesses are typically handled in systems by routing all undefined addresses to the default slave device. The default slave returns an error condition to a corresponding master device and software for recovery. Such accesses could be considered system anomalies.